In the design of operating systems, designers often attempt to develop operating software that can run on many diverse hardware platforms. This helps free the operating system from unnecessary hardware constraints that would otherwise render the operating system software unportable from one hardware device to another. To accomplish this goal, designers typically define a hardware abstraction layer (HAL) which describes the interface between low level system software components and hardware dependent software that runs on the underlying hardware. This layer is designed to enable interaction between essentially the same operating system and many diverse types of underlying hardware.
Interrupt handling is one feature that is usually defined in the hardware abstraction layer. An "interrupt" is a request-for-attention signal that can be passed by either hardware or software to a computer's CPU (Central Processing Unit). Interrupts can occur for many reasons, ranging from normal to highly abnormal situations, including service requests from hardware, errors in processing, program attempts to do the impossible, and memory problems. A "hardware interrupt" is a request for service generated by hardware components, such as a keyboard, mouse, disk drive, I/O port, and microprocessor.
The interrupt causes the CPU to suspend its current operations, save the status of its work, and transfer control to a special routine known as an "exception handler". The exception handler typically resides in the CPU at a known address. When an interrupt occurs, the CPU begins executing code at that location. The exception handler determines the cause of the interrupt and then services it by calling an appropriate set of instructions to be carried out.
The exception handler initiates different instructions for different types of interrupts. More specifically, each type of interrupt has an associated dedicated routine, known as an "interrupt service routine" or ISR. When a CPU receives interrupt requests from more than one source, the exception handler invokes a hierarchy of permission levels, called "interrupt priorities", to determine which of the interrupts is handled first.
To handle multiple concurrent interrupts, conventional exception handlers require several instructions to first determine the cause of the interrupt, then check priority, and then find the appropriate ISR to service the interrupt. This results in slower handling and lower performance. Although this speed and performance is acceptable in many desk-top applications, it will not support real-time operating systems which must execute interrupts at very high speed and efficiency.
The performance factor is further complicated by the desire to handle prioritized sets of interrupts from many diverse hardware platforms. Different hardware platforms often have different interrupts and dissimilar interrupt priorities. To be acceptable, an exception handler should provide: (1) real-time response for hardware interrupts, (2) dynamic setting of interrupt priorities, and (3) dynamic registering of exception handlers.
It is an object of this invention to provide an exception handler that can be dynamically configured to handle diverse sets of differently prioritized interrupts on a real-time basis.
It is noted that in some operating environments, there can be a slight distinction between an "exception" and an "interrupt". However, the distinction is not important for purposes of this disclosure, and the terms will be used interchangeably throughout. Both "exceptions" and "interrupts" refer to requests or conditions that cause the CPU to temporarily stop its present task and locate instructions in a separate routine for handling them.